Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES

Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES

am 17.05.2009 17:15:00 von Jeff Trawick

--000e0cd24d7e330de0046a1d2426
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Tue, May 12, 2009 at 9:17 AM, wrote:

> Author: covener
> Date: Tue May 12 13:17:29 2009
> New Revision: 773881
>
> URL: http://svn.apache.org/viewvc?rev=773881&view=rev
> Log:
> backport 772997, 773322, 773342 from trunk.
> Reviewed By: jorton, rpluem, covener
>
> Security fix for CVE-2009-1195: fix Options handling such that
> 'AllowOverride Options=IncludesNoExec' does not permit Includes with
> exec= enabled to be configured in an .htaccess file:
>
> * include/http_core.h: Change semantics of Includes/IncludeNoExec
> options bits to be additive; OPT_INCLUDES now means SSI is enabled
> without exec=. OPT_INCLUDES|OPT_INC_WITH_EXEC means SSI is enabled
> with exec=.


Current mod_perl tarballs reference OPT_INC_WITH_EXEC as part of mapping the
httpd API into perl, and the mod_perl build fails because of this.

("modperl_config.c", line 525: undefined symbol: OPT_INCNOEXEC)

While I don't understand why the mod_perl mappings are created at release
time against who knows what httpd, it brings up an interesting httpd issue
anyway.

If some module does have OPT_INCNOEXEC baked in (32), it matches what
2.2.12+ thinks is OPT_INC_WITH_EXEC. Similarly, the old OPT_INC_WITH_EXEC
(previously called OPT_INCLUDES), maps what 2.2.12+ thinks is
OPT_INCLUDES-without-exec.

We could swap the values of OPT_INCLUDES and OPT_INC_WITH_EXEC to lessen the
chance of some theoretical module making the wrong decision.

We can also define OPT_INCNOEXEC to something (either the new OPT_INCLUDES
or "Get your mod_perl patch at XXX").

--000e0cd24d7e330de0046a1d2426
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, May 12, 2009 at 9:17 AM, tr"><> pan> wrote:
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Author: covener

Date: Tue May 12 13:17:29 2009

New Revision: 773881



URL: arget=3D"_blank">http://svn.apache.org/viewvc?rev=3D773881&a mp;view=3Drev a>

Log:

backport 772997, 773322, 773342 from trunk.

Reviewed By: jorton, rpluem, covener



Security fix for CVE-2009-1195: fix Options handling such that

'AllowOverride Options=3DIncludesNoExec' does not permit Includes w=
ith

exec=3D enabled to be configured in an .htaccess file:



* include/http_core.h: Change semantics of Includes/IncludeNoExec

=A0options bits to be additive; OPT_INCLUDES now means SSI is enabled

=A0without exec=3D. =A0OPT_INCLUDES|OPT_INC_WITH_EXEC means SSI is enabled<=
br>
=A0with exec=3D.

Current mod_perl tarballs reference O=
PT_INC_WITH_EXEC as part of mapping
the httpd API into perl, and the mod_perl build fails because of this.


("modperl_config.c", line 525: undefined symbol: OPT_INCNOEXE=
C)

While I don't understand why the mod_perl mappings are create=
d at release time against who knows what httpd, it brings up an interesting=
httpd issue anyway.


If some module does have OPT_INCNOEXEC baked in (32), it matches what 2=
..2.12+ thinks is OPT_INC_WITH_EXEC.=A0 Similarly, the old OPT_INC_WITH_EXEC=
(previously called OPT_INCLUDES), maps what 2.2.12+ thinks is OPT_INCLUDES=
-without-exec.


We could swap the values of OPT_INCLUDES and OPT_INC_WITH_EXEC to lesse=
n the chance of some theoretical module making the wrong decision.

W=
e can also define OPT_INCNOEXEC to something (either the new OPT_INCLUDES o=
r "Get your mod_perl patch at XXX").




--000e0cd24d7e330de0046a1d2426--